Дипломная диссертация на тему: "Проектирование и разработка естественно-языкового диалогового интерфейса к реляционным базам данных" (часть1)

Руководитель:Дацун Н. Н.

Автор: Марченко Е. Е.

На этой странице отображена информация по таким темам:

ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ, СИМВОЛОВ, ЕДИНИЦ, СОКРАЩЕНИЙ И ТЕРМИНОВ

AG-Table (Answer Generate Table) – таблица генерации ответов;

Application – приложение;

ASR (Automatic Speech Recognition) – автоматическое распознование речи;

Command control – командное управление;

Ds (Dialog System) – диалоговая система;

GUI (graphical user interface) – графический польхзовательский интерфейс;

Grammar – грамматика;

NLUParser (Natural Language Understanding Parser) – парсер системы,

понимающей естественный язык;

NLU-система – система, понимающая естественный язык;

Rule – правило;

SUI (sound user interface) – звуковой пользовательский интерфейс;

SG-Table (Script Generate Table) – таблица генерации скриптов;

Term – терминал;

TTS (text to speech) – общее название технологий перевода текстовой строки в речь;

User – пользователь.

ВВЕДЕНИЕ

Данная работа посвящена изучению естественно-языковых диалоговых интерфейсов для реляционных баз данных. Естественно-языковые интерфейсы получают все более широкую область применения в связи с ростом численности пользователей персональных компьютером и с ростом мощности технической базы.

Применение естественно-языковых диалоговых систем возможно как на локальной машине, так и в сети Интернет. Разработка естественно-языковых интерфейсов необходима для наибольшего привлечения пользователей. Существует несколько подходов решения проблемы взаимопонимания человека и компьютера. На основе каждого из подходов разрабатывались естественно-языковые диалоговые системы. Наиболее известными фирмами, имеющими подобные системы, являются Dragon, L&H, AT&T, KeyWare и др. К сожалению, в каждой из этих систем есть свои недостатки и, кроме того, фирмы не заинтересованы в распространении информации о реализации механизма работы системы.

В данной работе предпринята попытка анализа всех необходимых механизмов естественно-языковых диалоговых интерфейсов. Разработана примерная структура подобного интерфейса, и кроме того предложены наиболее оптимальные подходы для реализации естественно-языкового диалогового интерфейса.

Таким образом, данная работа может быть использована при проектировании естественно-языковых диалоговых интерфейсов.

 

1 Анализ предметной области и содержательная постановка задач работы

1. 1 Анализ сферы применения естественно-языкового диалогового интерфейса

Данная разработка посвящена созданию естественно-языкового диалогового интерфейса к реляционной базе данных. База данных может хранить любую информацию, и первоочередной задачей естественно-языкового интерфейса является облегчение работы пользователя с имеющейся информацией. Соответственно, простота работы и ясное понимание того, что именно нужно запросить у базы данных для получения результата, создает благоприятное впечатление у пользователя.

В нашем случае реляционная база данных хранит информацию о продуктах питания (о каких продуктах есть информация в базе, наличие продуктов на складе, их цена и многое другое). Таким образом, нетрудно понять, что данная разработка может быть использована прежде всего, в сфере маркетинга в соответствии с одной из альтернативных концепций осуществления коммерческой деятельности, а именно в соответствии с концепцией сбыта. Концепция сбыта утверждает, что потребители будут покупать товар лишь в том случае, если будут использоваться различные методы продаж (например, электронный (как в нашем случае)) и имеется достаточное количество потенциальных потребителей. По сути, комплекс из базы данных и естественно-языкового диалогового интерфейса можно назвать "электронным продавцом".

Вопрос о количестве потенциальных потребителей не обсуждается, поскольку на продукты питания всегда есть достаточное количество потребителей. Если же база данных хранит в себе какие-либо другие значения, то, прежде всего, необходимо провести маркетинговые исследования. Исследования необходимо провести по таким направлениям: насколько соизмеримы объемы продаж в реальной торговой точке и объем продаж "электронного продавца", окупится ли покупка или разработка естественно-языкового интерфейса, проследить динамику спроса в реальной торговой точке и при обращении к базе данных. Конечно, здесь также очень важным вопросом является как удобство работы с интерфейсом, легкость "понимания" системой, так и то, где размещены "электронные продавцы" (например, покупатель физически далеко находится от места, где он сможет получить свой продукт и другое).

Построение подобного диалогового интерфейса является мероприятием по стимулированию сбыта и соответствует принципу маркетинга "стимулирование продаж и построение эффективных форм обслуживания". К мероприятиям по стимулированию сбыта можно отнести использование подобного интерфейса в связи с тем, что посредством его выполняется налаживание коммуникации между производителем и потребителем, что относится к коммуникационной стратегии любого отдела по сбыту.

Итак, почему же экономическая сущность данной системы рассматривается именно с точки зрения маркетинга? Это связано с тем, что основной целью маркетинга является поиск новых альтернативных путей сбыта, улучшение существующих и анализ этих путей. Маркетинговая политика предприятия всегда направлена на создание эффективных условий для продажи товара. В структуре маркетинга рассматривается и рынок, и покупатель, и непосредственно товар. Создание системы, понимающей покупателя и эксплуатация ее может быть выгодна по многим экономическим и практическим причинам. Они будут более подробно изложены ниже.

Нужно просто понять, что естественно-языковые интерфейсы как способ коммуникации покупателя и магазина реального, а значит что и производителя прямо или косвенно, значительно расширяют возможности маркетинговой политики фирмы. Естественно-языковой диалоговый интерфейс в сочетании с базой данных, конечно, позволяет во-первых создать сеть "виртуальных магазинов" и во-вторых автоматизировать процесс продажи.

Чем интересен первый путь применения. Прежде всего, нужно отметить, что идея "виртуального магазина" уже очень давно волнует умы многих разработчиков. Связано это с тем, что сеть Интернет вообще посещает очень большое количество людей во всех странах мира. Причем, специфика таких магазинов такова, что не важно физическое месторасположение человека. Имея какую-либо квитанцию или что-либо еще, подтверждающее, что этот товар куплен, пользователь может получить его физически в любой точке мира либо получить его по почте, что уже менее удобно. При пересылке по почте нужно учитывать специфику товара (не скоропортящийся), срок получения товара, затраты на транспортировку, разработать соответствующую упаковку.

Конечно, так сказать "оторванность" от физического места расположения, как товара, так и покупателя очень важное преимущество. Например, человек может, не выходя из дому заказать себе любой товар. Затем, проблема создания магазина в Интернете волнует коммерсантов, а вместе с ними и разработчиков еще и потому, что возможно продавать товар и рекламировать его. Ни для кого не секрет, что по уровню эффективности реклама в Интернете занимает первое место по сравнению с другими носителями рекламных сообщений, такими как телереклама, радиореклама, пресса, почтовая реклама и другие. Это дает двойной эффект при развертывании коммерческой деятельности в Интернете: есть реклама и сразу же есть место покупки, нужно лишь просто перейти по соответствующей ссылке. В связи с все растущим количеством посетителей Интернета коммерсант может быть уверен, что высокий уровень продаж ему гарантирован.

Но надо отметить, что технологии не развиты еще достаточно хорошо для создания такого рода магазинов, хотя в сети Интернет повсеместно предлагают что-либо приобрести. Почему же в этой сфере так важно применять естственно-языковые интерфейсы? Ответ очень прост. Большинство пользователей Интернета не являются профессионалами в сфере компьютерных технологий. Если разместить базу данных на сервере и создать возможность доступа к информации по сети, то, конечно же, объем посетителей сразу же снизится. А если взять на вооружение возможности естественно-языковых диалоговых интерфейсов, то конечно же их использование привлечет большее число покупателей и все они потенциально смогут купить. Не возникнет таких казусов: человек заинтересован в товаре и хочет его купить, но не знает как это сделать.

Данная технология построения естественно-языкового диалогового интерфейса применима к любому языку и к любой информации, которая может быть достаточно формализована. В данной разработке информация представлена в виде реляционной базы данных, но в будущем технология может быть дополнена средствами для работы с информацией других типов. В данной работе не этот вопрос является принципиальным. Главным является создание такого интерфейса, то есть создание ряда условий, при которых пользователь чувствовать себя комфортно, а компьютер будет понимать, и реализовывать все пожелания пользователя.

Чем интересен второй вариант. Использование на рабочем месте "электронного продавца" очень удобно для коммерсанта. Связано это с тем, что исчезает проблема человеческого фактора. Во-первых, при использовании "электронного продавца" отсутствую проблема недостатка в кадрах либо невыхода персонала на работу. Автоматически снимается проблема заработной платы. Кроме того, правильно запрограммированная система не будет ошибаться и создавать недостачи. Также важно отметить и то, что система всегда очень уважительно обслужит клиента и предложит все, что есть на складе (вид продукции, ее количество, цена). Система всегда точно знает, что предложить и, в связи с этим, экономит время покупателя. Кончено, все это возможно лишь в том случае, что есть связь между покупателем и информацией о наличии товаров. Этой связью и является разрабатываемый естественно-языковой интерфейс. Именно с его помощью возможна коммуникация.

Вышеперечисленные черты являются положительными сторонами использования "электронного продавца", а поскольку естественно-языковой интерфейс является ключевым звеном этой системы, то и положительными чертами естественно-языкового интерфейса. При этом следует учитывать факторы, которые влияют на возможность внедрения такой системы. Основная проблема - это проблема разработки такой системы или ее покупка. Также возникает необходимость приглашать на работу администратора баз данных и некоторый другой обслуживающий персонал, либо пользоваться услугами сторонней фирмы.

Конечно, принятию решения о внедрении такой системы предшествует сложный функционально-стоимостной анализ (если фирма разрабатывает естественно-языковой интерфейс своими силами) либо стоимостной анализ (если покупает систему). При любом анализе используются ключевые показатели: стоимость системы, объем продаж, норма прибыли и многие другие. Разработка и покупка подобных систем очень капиталоемки, поэтому подобные системы в нашей стране могут позволить себе лишь достаточно крупные фирмы, беспокоящиеся не только о своей прибыли, но и имидже фирмы.

Но не только использование естественно-языковых интерфейсов должно быть объектом анализа маркетинга, но и сам естественно-языковой интерфейс как продукт. Важность такого анализа связана, прежде всего, с тем, что интерес к подобным технологиям возрастает с каждым годом и разработчикам подобных интерфейсов надо будет позаботиться о функциональных возможностях интерфейса, об удобстве работы с системой, об уровне понимания и о других показателях.

Также есть еще один способ применения подобных интерфейсов. Оказание различного рода услуг, например обучение либо возможность общаться для людей, которые физически не в состоянии покинуть свой дом. Конечно, до того момента как будет разработана эта сфера применения естественно-языковых диалоговых интерфейсов пройдет еще несколько лет. Но тем не менее, возможность применения в этой сфере подобных интерфейсов существует. Требуется только базу данных преобразовать в базу знаний, что позволит людям ходить в музеи с гидом без физического присутствия в музее, а гидом буде наш естественно-языковой диалоговый интерфейс, заказывать билеты и многое другое.

Итак, подводя итог всему вышесказанному, можно сделать выводы об экономической сущности естественно-языковых диалоговых интерфейсов. Естественно-языковые диалоговые интерфейсы, используемые в сфере маркетинга, являются основным моментом при автоматизации процесса продажи, минимизируя время, трудозатраты, возможные ошибки и формируя у покупателя благоприятное впечатление от покупки. Кроме того, минимизируя трудозатраты, естественно-языковые диалоговые интерфейсы косвенно способствуют использованию человеческих усилий в каких-либо других, может быть более важных отраслях сферы производства и услуг.

В сущности, можно было бы не разрабатывать подобные интерфейсы, а ограничиться уже существующими системами ведения диалогов (например, диалог при пользовании банкоматом). Но в этом случае объем покупателей либо пользователей данной системой будет намного ниже. В связи с этим разработчики ставят перед собой задачи разработки естественно-языковых интерфейсов.

1. 2 Концептуальное описание естественно-языкового диалогового интерфейса

Данная задача может быть рассмотрена как две взаимодействующие подзадачи. Первая часть - это взаимодействие интерфейса с пользователем. Здесь непосредственно должен быть реализован алгоритм понимания смысла того, что сообщает пользователь. То есть должно быть реализовано множество выражений, которые пользователь может сказать, а система таким образом должна понять. Кроме всего прочего, интерфейс должен конвертировать смысл сказанной фразы в какое-либо внутреннее представление. Это может быть уже существующий язык, например, Пролог, VBScript. Это может быть какое-либо свое внутреннее представление. Представление во внутренних кодах нужно для понимания смысла запроса пользователя и трансляции этого смысла в запросы SQL.

Именно этим и занимается вторая основная подзадача. После формирования запроса во внутреннем представлении необходимо представить информацию на языке, понятном для базы данных. Таким образом, происходит трансляция в SQL.

Выше изложен только механизм обращения к базе данных. Возврат информации осуществляется в обратном порядке. База данных на запрос отвечает множеством записей из базы данных. Результат транслируется во внутреннее представление, затем во фразы естественного языка и выдается пользователю как ответ. Затем пользователь снова обращается и так далее.


Рисунок 1. 1. Порядок работы естественно-языково интерфейса

Необходимо отметить, что в задачи естественно-языкового диалогового интерфейса входит лишь осуществление связи между пользователем и базой данных. Результаты запросов формирует сама база данных, а интерфейс лишь преобразовывает их в естественный язык.

Итак, концептуальное решение задачи заключается в создании такой системы. Конечно же, это лишь первое приближение к подобному вопросу. Очень важен выбор метода представления естественного языка, способы отражения смысла задачи, классификация задач и многое другое. Все это будет обсуждаться ниже. На данном этапе важно разработать алгоритм взаимодействия естественно-языкового диалогового интерфейса с пользователем и базой данных, и понять, что он должен обеспечивать корректную работу с каждой стороной.

В настоящее время на рынке программного обеспечения представлено много программ распознавания и синтеза речи. Над этой проблемой работают многие ведущие мировые компании, такие как L&H, Dragon, IBM и др. Успехи в данном направлении являются отправной точкой для более высокого уровня общения человека с компьютером, а именно, диалога человека с компьютером на естественном языке.

Таким образом, перед разработчиками голосовых интерфейсов ставится задача понимания естественной речи. Более точно, понимание смысла сказанного. Именно понимание смысла фраз пользователя позволяет строить диалоги и с помощью диалогов решать задачу более высокого уровня, задачу понимания цели, которой хочет достигнуть пользователь.

Построение диалогов определено многими причинами. Пользователь не всегда может четко сформулировать цель, или не предоставить необходимые данные для решения поставленной задачи (цели пользователя), или предоставить неверные данные, и т.д.

 

2 Теоретическая постановка задачи проектирования естественно-языкового диалогового интерфейса. Выбор и обоснование методов решения задач

2. 1 Теоретическая постановка задачи проектирования естественно-языкового диалогового интерфейса

Для определения цели, которой хочет достигнуть пользователь, или другими словами, какую задачу он ставит системе, разрабатываются различные интерфейсы. Самым распространенным на сегодняшний день, является всем хорошо знакомый – графический пользовательский интерфейс, или GUI. Этот интерфейс обеспечивает ввод данных в компьютер, вызов нужных приложений, предоставление информации пользователю и многое другое. Но как бы он не выглядел привычно, он не является удобным с точки зрения естественного человеческого общения, когда одним из самых важных каналов предоставления и получения информации является голос.

Сейчас многие компании занимаются созданием так называемых голосовых пользовательских интерфейсов (sound user interface) или SUI, в основе которых лежит решение проблемы понимания смысла пользовательской фразы.

Мы не будем говорить о проблемах распознавания речи, о достоинствах и недостатках этих систем. К сожалению, ошибки распознавания есть и всегда будут. Но для нашей работы, отправной точкой будет считаться тот факт, что фраза распознана, то есть речевой поток трансформирован в строку символов. И на самом деле, для нас не важно, как появилась эта строка символов, в результате работы программы распознавания, или пользователь ее ввел с клавиатуры. Для нас важно одно, как понять смысл фразы, которая содержится в строке.

Термин “понимание смысла“ мы будем интерпретировать как процесс трансляции фразы пользователя в некоторое адекватное действие, совершаемое системой.

Если говорить о системах понимания естественной речи или NLU-ситемах, то можно выделить два типа таких систем:

а) командные системы (command control). Этот тип NLU-системы интерпретирует единичную фразу пользователя в набор конечных команд, которые выполняются компьютером. С помощью таких систем строится голосовое управление компьютерными приложениями, например, Microsoft Word. Эти системы полностью содержат в себе команды управления конкретным приложением и транслируют голосовые команды пользователя в команды управления приложением. Следующий пример показывает работу системы command control.

Пример:

ПОЛЬЗОВАТЕЛЬ: Открыть Microsoft Word.

КОМПЬЮТЕР: Запускает приложение Microsoft Word.

ПОЛЬЗОВАТЕЛЬ: Открыть File.

КОМПЬЮТЕР: Открывает диалоговое окно открытия файла.

ПОЛЬЗОВАТЕЛЬ: Изменить путь.

КОМПЬЮТЕР: Изображает дерево изменения директорий.

И т.д.

ПОЛЬЗОВАТЕЛЬ: Выйти.

КОМПЬЮТЕР: Закрывает приложение Microsoft Word.

б) диалоговые системы (dialog system). Эти системы более широко интерпретируют понятие естественного языкового общения и в своей основе содержат диалог пользователя с компьютером для выяснения конечной цели, которую хочет достичь пользователь и получения от него необходимых данных для решения поставленной задачи.

Пример:

ПОЛЬЗОВАТЕЛЬ: Я хотел бы поехать в Киев.

DS: Каким транспортом вы бы хотели воспользоваться?

ПОЛЬЗОВАТЕЛЬ: Конечно, лучше поездом.

DS: Каким транспортом вы бы хотели воспользоваться?

ПОЛЬЗОВАТЕЛЬ: Конечно, лучше поездом.

DS: Когда вы хотите быть в Киеве?

ПОЛЬЗОВАТЕЛЬ: 25 декабря.

DS: Перечисляет возможные рейсы и просит выбрать нужный

ПОЛЬЗОВАТЕЛЬ: Сообщает нужный рейс.

…

DS: После того как получена полная информация, бронирует билет.

Как видно из данного примера, что в течение диалога, DS может работать не с одним, но несколькими приложениями, как базой данных движения поездов, наличием мест, бронированием билетов и т.д.

Система command control понимает фразы естественного языка только лишь как набор команд. Поэтому в ее задачи не входит понимание смысла фразы пользователя. Система такого типа должна лишь сопоставить фразу пользователя с тем множеством фраз, которые заложены внутри нее, и при совпадении выполнить требуемое действие. Конечно, в этом случае можно говорить лишь об управлении с использованием ограниченного числа команд, представленных на естественном языке.

При работе с системы. DS используется абсолютно иной подход. Здесь система нацелена на понимание смысла сказанного. Это возможно благодаря использованию некоторой логической структуры, на которую отображается речь пользователя.

Совершенно очевидно, что любой тип NLU системы оперирует со смыслом пользовательских фраз. Существует несколько теорий определения смысла языковых фраз. Это и попытки отображения пользовательской фразы на семантическую модель представления мира, и попытки определения смысла путем разложения фразы на части речи и анализа структуры фразы (так называемая tag/chunk технология, которая определяет части речи фразы –tags, а затем смысловые куски -chunks, но не определяет смысл фразы в нашем понимании и хороша для разработки компьютерных переводчиков) и др.

Для представления естественного языка при разработке данного интерфейса использовалась теория грамматик. Предпосылки для использования именно этого способа представления естественного языка следующие:

В случае построения command control системы, пользователь произносит ограниченное множество фраз, определенное свойствами того приложения, которым он в данный момент управляет. Другими словами, это только те фразы, которые содержат в себе команды управления текущим приложением.

В случае построения DS системы, пользователь может произнести также ограниченное множество фраз, определенное предметом диалога и текущим состоянием диалога. Т.е., трудно себе представить, что, когда речь идет о бронировании билетов на самолет (предмет диалога) и система ожидает ответа о количестве билетов (текущее состояние диалога), пользователь может задать вопрос о здоровье лидера какого-нибудь политического движения. Хотя и такое возможно, но система будет считать это ошибкой и попытается вернуть пользователя в нужное русло диалога.

Всякое множество фраз можно описать с помощью грамматики, которая определяет набор слов, из которых строятся фразы и способы построения возможных фраз. Можно, конечно, иметь полный список возможных фраз, но такая система будет громоздкой и не эффективной, а также довольно трудно модифицируемой. Например, в случае разработки диалога, связанного с продажей напитков, трудно себе представить как можно дополнять такой список фраз в случае поступления новых типов и наименований напитков. Это не только добавление новых слов, но и генерация всех возможных фраз, в которых может встречаться новое слово. С этой задачей успешно справляется грамматика, поскольку оперирует с понятием правил построения фраз, а не только со значениями слов. Далее, при описании грамматики, это станет понятней.

С помощью грамматики можно выделять подмножество фраз, которые ожидаются от пользователя в текущий момент. Так называемые правила грамматики, которые содержат подмножества фраз и активизируются в нужный момент, в зависимости от текущего состояния диалога или активизации того или иного приложения.

С помощью грамматики, можно построить соответствие между каждой фразой пользователя и выходной грамматикой. Выходная грамматика – это фраза, содержащая набор команд (или одну команду), которая будет передана в соответствующее приложение для выполнения. Если в результате парсирования (анализа) входной фразы (фразы пользователя) была получена выходная фраза (тот самый набор команд), мы считаем, что смысл пользовательской фразы понят. Здесь следует отметить, что выходная грамматика может содержать не только команды управления конкретным приложением (что хорошо для систем command control), но и командные строки, которые могут передаваться в некую диалоговую систему для отображения текущего состояния диалога и передачи данных в диалоговую систему. Другими словами, фраза пользователя транслируется в некоторую строку, которая в свою очередь передается в нужное приложение (с точки зрения грамматики, DS является тоже приложением) и является для него понятным.

Для лучшего понимания закономерностей построения грамматики необходимо привести некоторые определения теории построения грамматик. Прежде всего, необходимо ввести понятие алфавита.

Алфавит – любое множество символов. Алфавит не обязан быть конечным и даже счетным, но во всех практических приложениях он будет конечным. Например, латинский алфавит – множество, состоящее из 26 строчных и прописных букв. Термины “буква” и “знак” будут использоваться как синонимы термина “символ” для обозначения элемента алфавита. При расположении символов одного за другим, получаем последовательность – цепочку символов или “лексему”. Термины “предложение”, “слово”, “строка” – синонимы термина цепочка. При этом следует учесть существование пустой цепочки (мы будем обозначать ее символом е*).

Формально цепочки в алфавите Е* можно определить таким образом: е* - цепочка в Е*; если х – цепочка в Е* и а принадлежит Е*, то ха – цепочка в Е*; у – цепочка в Е* тогда и только тогда, когда она является такой в силу предыдущих двух пунктов. Возможны такие операции над цепочками, как конкатенация (сцепление) цепочек, обращение (запись последовательности в обратном порядке), выделение префиксов и суффиксов.

Итак, мы вплотную подошли к определению языка.

Язык в алфавите Е* - множество цепочек в алфавите Е*. Под это определение подходит почти любое определение языка. При этом необходимо учесть, что пустое множество – язык; множество {e*}, содержащее только пустую цепочку, - тоже является языком. При этом пустое множество и множество {e*}являются различными языками. Так как языки, по сути, есть множества, то к ним применимы все операции, применимые к множествам.

Проблемой естественных языков является то, что все они – контекстно-зависимы. То есть для эффективного ведения диалога, системе недостаточно просто знать ответ пользователя, а нужно также хранить информацию о предыдущих ответах и получать информацию от внешнего мира.

Информация от внешнего мира должна учитываться в связи с тем, что многие слова многозначны и смысл их зависит в значительной степени от окружающего мира. То есть, чтобы определить смысл и структуру предложения, необходимо исследовать все окружение: окружающие отношения, свойства предмета и даже информацию о говорящем.

Идея подхода к ведению естественно-языкового диалога с машиной заключается в выборе узкоспециализированной области, что позволяет информацию, которую можно извлечь из предложений естественного языка, представить в виде древовидной структуры. Этот подход охватывается понятием контекстно-свободных грамматик. А уже расширение возможностей диалогового интерфейса возможно при подключении различных грамматик.

Грамматика – математическая система, определяющая язык. В грамматике, определяющей язык L, используют два конечных непересекающихся множества символов – множества нетерминальных символов (множество N’) и множество терминальных символов – Е*. Терминальные символы определяют цепочки языка (слова). Множество же N’ служит для определения синтаксических переменных.

Сердцевину грамматики определяет конечное множество Р правил образования, которые описывают процесс порождения цепочек языка. Неформально, нетерминал можно рассматривать как переменную, которая может принимать значения цепочек терминалов. Язык, определяемый грамматикой, - это множество цепочек языка, состоящих только из терминальных символов.

Итак, грамматика есть четверка G=(N, E, P, S) где: N – конечное множество нетерминалов; E – непересекающееся с N множество терминалов; Р – конечное множество правил (элемент (а,b) множества Р есть правило и записывается в виде а->b); S – выделенный символ из N, называемый начальным символом. Необходимо отметить, что грамматика определяет язык рекурсивным образом.

Грамматика состоит из:

Другими словами, разработчик должен представить себе все возможные диалоги, затем представить все возможные фразы пользователя в рамках решаемой задачи, сгруппировать эти фразы по группам, которые будут представлены на каждом этапе диалога, попытаться определить правила построения фраз и таким образом построить грамматику “естественного языка”, но только для совершенно конкретной предметной области (в нашем случае торговля напитками). Можно, конечно иметь и много грамматик, разбивая на подмножества решаемую задачу, и в нужный момент их переключать.

Важно уяснить себе, что в нашей технологии грамматика строится для конкретного диалога и определяет набор слов, которые могут употребляться, и правила построения фраз из этого набора слов. Это совсем не перечисление всех возможных фраз (хотя может быть и такой подход), но перечисление правил построения фраз. Это очень важно. Эти правила определяет разработчик, и от того, насколько он хорошо их построил, будет зависеть качество диалога. Задача не простая, но вполне решаемая. Нужно определить какую-то очень узкую предметную область, чтобы можно было построить эффективное приложение, не нагружая себя разработкой очень сложных диалогов и грамматик.

Далее, понятие “понимание смысла фразы”, мы будем интерпретировать следующим образом:

2. 2 Синтаксис грамматики

2. 2. 1 Понятия входной и выходной грамматик

Множество фраз, которое может быть распознано системой, задается грамматикой в форме описания. Мы называем такую грамматику - входной грамматикой. Каждая входная грамматика состоит из терминалов (единичных слов) и нетерминалов (последовательность терминалов и нетерминалов), описание которых приводится ниже.

2. 2. 2 Терминал

Терминал – последовательность любых символов, исключая следующие: пробел,символ “|”, символ табуляции, символ перевода каретки, символ перехода на новую строку, символ “<”, символ “>”, символ “{“, символ “}”, символ “[“, символ “]”.

Примерами терминалов могут быть отдельные слова: document, file, help.

2. 2. 3 Нетерминал

Нетерминал – окруженная угловыми скобками(“<>”), произвольная последовательность символов, которая задана в нижнем регистре латинского алфавита и имеет те же ограничения, что и терминалы грамматики.

<main>, <word>, …

Угловые скобки в данном случае являются признаком нетерминала.

Нетерминал определяет некоторую последовательность терминалов или нетерминалов, которая записывется после знака “:”, стоящего после имени нетерминала, который эту последовательность определяет. Каждый такой нетерминал должен быть записан с начала новой строки, содержать только один символ “:”, следующий сразу за ним, и заканчиваться символом “;”, обозначающим конец определения нетерминала. Терминалы и нетерминалы в последовательности отделяться друг от друга символами пробел, табуляции или возврата каретки. Например:

<main>: Open document;

<color>: Black;

<command>: Set color of the

current line in <color>;

Нетерминалы с одним и тем же именем могут определять различные последовательности, что записывается либо как несколько определений нетерминала, заданных разными строками:

<color>: Red;

<color>: Blue;

<color>: White;

либо в одном определении нетерминала, где различные последовательности разделены символом “|”:

<color>: Red | Blue | … | White;

Кроме того, нетеминалы в своем определении могут содержать последовательности терминалов или нетерминалов, ограниченных квадратными скобками “[” и “]”. Это означает, что выделенная последовательность присутствует в нетерминале опционально. Например:

<command>: delete [the] line number two;

что определяет нетерминал <command> как

<command>: delete the line number two | delete line number two;

Каждая входная грамматика обязана определять целевой нетерминал <main>, который задает на верхнем уровне все множество входных фраз. Отсутствие этого нетерминала делает невозможным распознавание какой-либо входной строки.

Как уже говорилось ранее, входная грамматика описывает множество фраз, которое может быть распознано. Распознав некую фразу из этого множества, система должна отреагировать на нее посредством генерации соответствующей входной фразе выходной строки. Множество генерируемых всех выходных строк задается выходной грамматикой. Но существует ряд отличий в форме записи и определений.

2. 2. 4 Выходная грамматика

Выходная грамматика состоит из терминалов и нетерминалов. Нетерминалы выходной грамматики определяются также, как и нетерминалы входной, за исключением того, что их имена записываются в верхнем регистре клавиатуры (большими буквами) и запрещается использовать символы “|” и “[]” в определении нетерминала (запрещена опциональность и определение нескольких последовательностей для одного нетерминала).

Терминалы выходной грамматики делятся на несколько типов:

  • цифровое сообщение – любая последовательность символов, не заключенная в двойные кавычки и имеющая ограничения терминала входной грамматики;

  • строковое сообщение – любая последовательность символов (текст), заключенная в двойные кавычки. Если текст должен содержать кавычки, то непосредственно перед ними ставится символ #.

Например: “Hello #“my dier#” frend”, что задает нетерминал - Hello “my dier” frend;

  • голосовое сообщение – любой текст, заключенный в двойные кавычки, перед которым стоит ключевое слово Say. Например:
    Say“Hello #“my dier#” frend”.

Каждому типу терминала выходной грамматики соответствует свой набор данных, которые возвращаются программе после того, как фраза распознана. Выходная грамматика должна однозначно определять выводимую фразу, поэтому в ней запрещено использовать опциональность и ветвление для веток нетерминалов. Вместо этого введен подход динамического определения нетерминалов во время распознавания входной фразы грамматики. Все нетерминалы выходной грамматики, которые могут определять разные последовательности терминалов или нетерминалов, в зависимости от того, какая фраза была введена, должны быть записаны в определениях нетерминалов входной грамматики в любом месте последовательности. Для этого используются фигурные скобки “{}”.

После того, как входная фраза будет распознана, выходная грамматика будет содержать в себе определения только тех нетерминалов, которые встретились на пути распознавания фразы во входной грамматике, и определения отдельно заданных нетерминалов выходной грамматики. Такая динамически сформированная грамматика должна выводить одну фразу, которая и будет реакцией системы на распознанную команду. После введения следующей команды, новая последовательность выходных нетерминалов будет сформирована и т.д.

Все последовательности терминалов или нетерминалов, которые содержаться во входной грамматике и заключены в фигурные скобки, при этом не определяющие никакой нетерминал выходной грамматики (отсутствует знак “:” в начале последовательности после имени первого нетерминала), автоматически добавляются к определению выходного целевого нетерминала <MAIN>, если эта последовательность встретилась на пути распознавания фразы.

Динамически сформированная выходная грамматика может использовать рекурсивное определение своих нетерминалов. Например,

… {<NUMBER>: <NUMBER> <DIGIT>}…

В этом случае выходная грамматика будет интерпретирована в следующую последовательность правил:

<NUMBER1>: …, раннее определенный нетерминал;

<NUMBER2>: <NUMBER1> <DIGIT>;

Если при этом нетерминал, который встречается в последовательности, не был ранее определен, то его значение равно пустоте:

<NUMBER1>: ;

<NUMBER2>: <NUMBER1> <DIGIT>;

2. 2. 5 Директивы парсеру

Для того чтобы использовать в тексте грамматики набор правил, содержащийся в другом GSF файле, необходимо подключить его директивой :

#Include “Путь и полное имя файла”

ПРИМЕР: Include “D:\GSF\Inc.gsf”;

Есть 2 типа комментариев:

Однострочный - (//) действует до конца строки;

Многострочный - (/* … */) коментарий весь текст, заключенный символами /* и */.

Каждая грамматика имеет свой идентификатор. Он необходим, когда загружаются несколько грамматик одновременно.

Для задания имени грамматики статическая часть грамматики должна содержать директиву: #GramName “имя грамматики”.

2. 3 Выбор методов решения

В связи с тем, что естественный язык контекстно-зависим, то для описания контекстно-зависимых грамматик используются атрибуты. С их помощью можно передавать информацию из левой части порождающего правила в правую (унаследованные атрибуты) и из правой части в левую (синтезированные атрибуты). Преимущества атрибутивных грамматик в том, что они могут специфицировать и контекстно-свободные и контекстно-зависимые языки.

Важным моментом является неоднозначность грамматик (можно построить более одного дерева разбора) и реализация нисходящего разбора при синтаксическом анализе. Используемые грамматики обладают свойством

a->b

|a|<=|b|,

что определяет грамматику как контекстно-зависимую, то есть типа 1 по иерархии Хомского.

Но грамматики, используемые для работы нашего естественно-языкового диалогового интерфейса, сводимы к грамматикам типа 3 в связи с:

  • выбором узкоспециализированной области естественного языка. То есть имеется в виду, что для работы естественно-языкового диалогового интерфейса в сфере торговли напитками, например, будут использоваться только грамматики построения фраз из этой сферы, а для иного случая применения будут использоваться другие грамматики. Под понятием другие имеется в виду набор используемых лексем при сохраняющемся синтаксисе.

  • наличием в грамматике атрибутов. В нашем случае это динамически сформированная грамматика.

Следующим ключевым моментом является задание логической структуры, на которую отражается смысл фразы, сказанной пользователем.

Логическая структура – это структура данных, которая отображает состояние внешнего мира и информацию, сообщаемую пользователем. Анализируя логическую структуру, диалоговый engine задает запросы пользователю, генерирует ответы, изменяет внешний мир и сообщает информацию о нем.

Логическая структура представлена древовидной структурой, где листьями являются задачи. Каждая задача имеет приоритетность. Может быть “n” - важная, то есть без решения такой подзадачи невозможно решение основной задачи и “un” - неважная, где ее решение желательно для полноты информации.


Рисунок 2. 1. Пример логической структуры

Кроме того, если задача является динамически необходимой, то есть требуется получение дополнительной информации от пользователя, то система сама генерирует необходимые вопросы. При достаточности информации система генерирует некоторый код и создает запрос к базе данных. Предусмотрено наследование информации при помощи создания итерационных структур. Более полная информация приведена в главе3.

Продемонстрируем работу естественно-языкового интерфейса на примере части диалога. Естественно-языковой диалоговый интерфейс работает с базой данных, хранящей информацию о продуктах питания. Пусть имеются следующие таблицы.

 

Код

Наименование

Тип

Марка продукта

Цена

1

Славутич-экстра

1

1

1,5

2

Светлое

1

1

  

3

Нордическое

1

2

1,4

4

Черный принц

2

2

1,25

Таблица 2. 1 – Таблица “Пиво”.

код

тип

1

светлое

2

темное

Таблица 2. 2 – Таблица “Тип пива”.

код

марка

1

Славутич

2

Сармат

Таблица 2. 3 - Таблица “Марка пива”.

Примерный текст диалога:

Пользователь: Я хотел бы купить у вас пива.

DS: Какой именно вид пива вас интересует?

Пользователь: А какие виды у вас есть?

DS: У нас есть темное пиво и светлое пиво?

Пользователь: Мне нужно светлое.

DS: Могу предложить вам марки “Славутич” и “Сармат”.

Пользователь: “Славутич” мне подходит.

DS: В нашем ассортименте есть “Светлое” и “Славутич-экстра” этой марки.

Пользователь: Я хочу купить “Светлое”.

DS: Сколько бутылок Вы хотели бы купить?

И так далее.

При работе происходит следующее. Если информации системе явно недостаточно, как, например, в начале диалога, то пользователю будут заданы вопросы, конкретизирующие его пожелания. Система спрашивает: “Какой именно вид пива вас интересует”. Далее информация конкретизирована, и все ответы системы представляют из себя результаты запросов к базе данных, транслированные в естественный язык. Ниже приведено соответствие между фразами пользователя и запросами на языке SQL.

 

“А какие виды у вас есть?”

SELECT ТипПива.Тип, FROM ТипПива INNER JOIN Пиво ON ТипПива.Код = Пиво.Тип

GROUP BY ТипПива.Тип

ORDER BY ТипПива.Тип;

 

 

 

“Мне нужно светлое”

SELECT МаркаПива.Марка

FROM МаркаПива INNER JOIN Пиво ON МаркаПива.Код = Пива.марка

WHERE (((ТипПива.Тип)=1))

GROUP BY МаркаПива.Марка

ORDER BY МаркаПива.Марка;

 

 

“Славутич” мне подходит”

SELECT Пиво.Наименование

FROM Пиво

WHERE (((Пиво.Тип)=1) and (Пиво.Марка = 1))

ORDER BY Пиво.Наименование;

Таблица 2. 4 – Соответствие фраз пользователя и запросов на языке SQL.

Таким образом, основными позициями при создании естественно-языкового интерфейса являются:

3 Разработка технологии проектирования естественно-языкового диалогового интерфейса

3. 1 Описание структурно-функциональной схема естественно-языкового диалогового интерфейса

Структурно-функциональная схема естественно-языкового диалогового интерфейса может быть представлена в следующем виде, причем каждый из указанных блоков может быть детализирован. Структурно-функциональная схема системы должна содержать указанные выше основные элементы (позиции системы) и отвечать требованиям по функциональным характеристикам.

Охарактеризуем входные потоки системы. Итак, от пользователя поступает поток слышимых звуков. Блок распознавания речи (ASR) должен транслировать этот поток в строки, которые являются входным потоком для блока лексического и синтаксического анализатора (NLUParser). Выходным потоком этого блока является множество выходных конструкций, которые были созданы при трансляции фраз пользователя во внутреннее представление.

Выходные конструкции, называемые также выходными грамматиками, передаются в виде входного потока для ядра диалоговой системы - блока управления системой. Блок управления системой внутри содержит различные информационные потоки, структура которых будет описана ниже. Укажем лишь, что момент генерации внутреннего представления соответствует выявлению смысла фразы. То есть после синтаксического анализатора анализу подвергается только внутреннее представление фразы, как бы вычлененный смысл сказанного пользователем. Выходным потоком является смысл сказанного, транслированный в какой-либо язык (это может быть VBScript или SQL). В нашем случае трансляция осуществляется в SQL, и затем в виде входного потока подается приложению.

Для данной естественно-языковой диалоговой системы приложением является реляционная база данных. Обработав входную информацию, приложение реагирует каким-либо образом: выдает информацию, осуществляет действие. Таким образом, база данных отправляет информацию – результат запроса. Отправка осуществляется обратно в блок управления системой. И с этого момента начинается обратный проход: от набора записей к естественному языку.

Выходным потоком в этом случае является либо генерация ответа пользователю (в виде строки), либо действие (генерация кода и активизируя грамматики). В случае генерации ответа пользователю данная информация является входным потоком для блока синтеза речи в строку (блок TTS).


Рисунок 3. 1. Структура естественно-языкового интерфейса

В сущности, эта проблема состоит из трех крупных частей:

3. 2 Детальный анализ структурно-функциональной схемы естественно-языкового диалогового интерфейса

3. 2. 1 Уровень распознавания и синтеза речи

Первоочередной задачей системы является распознавание речи пользователя, то есть определение всех возможных значений множества языка, что в дальнейшем является начальными данными для работы лексического анализатора. В данной системе пользователь вводит фразы при помощи клавиатуры, таким образом, блок распознавания речи не используется. Это связано с тем, что все звуки, которые может произнести пользователь, уже представлены им при помощи клавиатуры в определенной машинной кодировке. Конечно, представление речи в электронном виде в значительной речи облегчает работу, поскольку сама задача по распознаванию речи является очень трудоемкой.

К сожалению, до настоящего времени не существует эффективных технологий по распознаванию речи. Задача очень трудоемка потому, что произношение отдельного человека даже в рамках одного языка очень индивидуально. При распознавании речи очень остро встает именно эта проблема. Задачу можно облегчить, унифицировав звуки, относящиеся к одной букве, каким-либо образом. Но до настоящего времени, эффективного механизма унификации нет. Кроме того, при решении такой задачи велики затраты по времени. В связи с этим, многие разработчики приходят к мысли, что имеет смысл настраивать распознающую систему под купившего ее человека. Но этот подход возможен лишь в том случае, если человек приобрел такую систему для личного пользования (например, управление компьютером).

Для нашей ситуации этот вариант не подходит, поскольку нельзя заранее определить все множество пользователей. Задачей данной системы не стояла реализация речевого ввода запроса пользователем, а понимание смысла речи. В связи с этим, данной блок детализироваться не будет. Возможность подключения подобного блока всегда существует и потому естественно-языковой диалоговый интерфейс может работать в комплексе с системой распознавания речи. Но сейчас естественно-языковые диалоговые системы находятся в разработке, и потому в данный момент ввод фраз пользователя осуществляется из списка фраз, которые в данный момент могут быть поняты (то есть при помощи правил переведены в выходные грамматики).

Этот уровень необходим только в том случае, если мы используем речевые технологии. Если же предполагается использование клавиатуры для ввода информации и отображение полученной информации на монитор, то нет необходимости реализовывать этот уровень.

На этом уровне расположены два блока:

ASR представляет собой систему, реализующую перевод естественной речи в текстовую строку. На сегодняшний день доступны подобные системы следующих фирм-производителей: L&H, Dragon, IBM, Nature.

Все эти фирмы используют одинаковый подход к проблеме распознавания речи. И реализуют два подхода к проблеме распознавания речи: ASR и Dictation. Эти подходы принципиально отличаются друг от друга. Если система ASR может распознать только ограниченный набор слов, который в него загружает пользователь, то система Dictation предназначен для режима диктования и понимает все слова языка. Естественно, что оба подхода применяются для различных целей. Но здесь нужно отдавать себе отчет, что режим Dictation очень ресурсоемкий и имеет процент распознавания гораздо ниже, чем ASR. И поскольку в нашем случае (в случае построения диалога) слова уже предопределены заранее при написании грамматик диалога, то имеет прямой смысл использовать ASR. Все слова грамматик загружаются в engine ASR перед запуском. И имеется возможность данный словарь слов перегружать в любой момент времени, т.е. если общий словарь диалога достаточно большой, то правильно будет загружать словарь только активной грамматики на данный момент. Это улучшит работу процесса распознавания речи.

Итак, данный блок может иметь два входа в зависимости от используемого подхода, первый для загрузки (перегрузки) словаря слов, которые могут быть распознаны, второй – для загрузки речевого сигнала (оцифрованная речь), или другими словами, речи пользователя. На выходе блок имеет символьную строку того, что сказал пользователь.

Естественно, речь идет о логическом представлении данной системы, поскольку конкретная реализация имеет и множество сообщений о событиях и состояниях системы в текущий момент, а так же интерфейсы для управления работой данного системы. Благодаря этому мы (наша программа) всегда будет знать распознана ли фраза (имеется ввиду на уровне распознавания речи) или нет, и может выполнить соответствующие действия. Отправить распознанную строку на парсирование или же сообщить пользователю, что его фраза не распознана. Если распознавание проходит очень плохо, то можно порекомендовать пользователю настроить программу распознавания под свой голос (такая возможность то же имеется). И многое другое.

TTS - система синтеза речи из символьной строки. На сегодня достаточно много фирм реализуют подобные программы (AT&T, CLSU, Dragon, Keyware). Отличаются они лишь качеством речи и скоростью работы.

На вход блока подается символьная строка, а на выходе получается голосовой поток, который передается дальше на звуковую карту.

3. 2. 2 Уровень парсирования пользовательских фраз

На этом уровне реализуются грамматики диалога, парсирование фраз (или понимания смысла сказанного) и управление диалоговой системой.

3. 2. 2. 1 Основные теоретические методы парсирования пользовательских фраз

Существуют различные теоретические методы, используемые при создании лексического и синтаксического анализаторов. Методы бывают восходящие, то есть начинают с предложения и идут к начальному символу и нисходящие, то есть начинают с начального символа и идут к предложению. Разрешается смешивать оба эти метода.

Предложение, читаемое слева направо, читается нормально, хотя с точки зрения читать его справа налево также просто (или даже проще). Методы также могут быть детерминированными и недетерминированными в зависимости от того, возможен возврат или нет. Возвратом называется отказ от решения применять конкретное порождающее правило при разборе. Недетерминированные методы разбора весьма дорогие с точки зрения памяти и времени и крайне затрудняют включение в синтаксический анализатор, выполняемых во время компиляции .

3. 2. 2. 2 Реализация лексического и синтаксического анализаторов в системе естественно-языкового диалогового интерфейса

Лексический и синатксический анализаторы в данной системе интегрированы в один механизм, называемый парсером.

Блок лексического анализа проверяет принадлежат ли фразы пользователя активному в данное время подмножеству фраз.

Блок синтаксического анализа ставит в соответствие словам пользователя выходные конструкции (синтаксис выходных конструкций описан выше) посредством использования грамматик. При проектировании данного естественно-языкового диалогового интерфейса используется следующий механизм.

Основными задачами, которые должен выполнять парсер, являются следующие:

Программа должна быть выполнена в виде независимого объекта, чтобы можно было ее использовать любыми приложениями.

Реализация грамматик заключается в описании правил построения пользовательских фраз и написания тех действий, которые необходимо выполнить диалоговой системе в случае понимания фразы.

Мы говорим о множестве грамматик, поскольку предполагаем течение диалога в необходимом русле и естественно, что в каждый момент диалога, пользователь говорит фразы, соответствующие данному моменту. Таким образом, в любой момент времени диалога мы можем делать активной ту или иную грамматику. (И соответственно, перегружать словарь в ASR, если он используется).

Пример. Представим себе систему, реализующую электронную торговлю. Пользователь уже сказал, что он хочет купить напитки, и мы активизируем грамматику <beverages>, которая определена нами в следующем виде:

<beverages>:

[<who>] [<needs>] <type> {“<v_type> = <type>;”};

<who>:

я [бы] | мне [бы] ;

<needs>:

<want> [купить] | <want> [приобрести];

<want>:

хочу | хотел [бы] | хочется | хотелось бы;

<type>:

кока кола | кока колу | [минеральная] вода | [минеральной] воды | пиво | пива;

Таким образом, мы определили, что во фразе пользователя обязательно должен присутствовать тип напитка (правило грамматики <type>), и несколько необязательных (опционально) правил, с помощью которых строится естесственная фраза. А так же словарь это грамматики.

Итак, словарь: я, мне, бы, купить, приобрести, хочу, хотел, хочется, хотелось, кока, кола, колу, минеральная, минеральной, вода, воды, пиво, пива.

Теперь, какие фразы пользователь может произнести:

... И т.д.

Не имеет смысла здесь перечислять все возможные фразы. Следует только сказать, что от того, как построены грамматики, зависит и естественность общения системы с пользователем. Другими словами, при проектировании грамматик нужно очень тщательно предусмотреть возможность произнесения той или иной фразы.

Когда же фраза произнесена и распознана, то строка, которая заключена в фигурные скобки, должна быть передана в диалоговый engine для выполнения. Это так называемая выполняемая грамматика. В нашем случае, вершина логической структуры диалога под названием <v_type>, будет нагружена значением того, что просит пользователь. (Пиво, минеральная вода или кока кола)

Здесь нужно сказать о формализации присваиваемых значений вершинам структуры. Т.е. не может вершина иметь значения “пиво” , “пива”, “пивка”, а только “пиво”. Поскольку это бы усложнило дальнейшую обработку данных. Для реализации такой формализации, парсер при парсировании реализует динамические переменные, которые можно использовать в выполняемых грамматиках. Т.е.

<beverages>:

[<who>] [<needs>] <type> {“<v_type> = <VAR>;”};

<type>:

кока кола {<VAR> = “кока кола”;} |

кока колу {<VAR> = “кока кола”;}|

[минеральная] вода {<VAR> = “вода”;}|

[минеральной] воды {<VAR> = “вода”;} |

пиво {<VAR> = “пиво”;} |

пива{<VAR> = “пиво”;};

При вводе вручную происходит загрузка словаря слов активной грамматики и начинает работу лексический анализатор. Если какие-либо слова из фразы пользователя не находятся в этом подмножестве, то система сразу должна отреагировать каким-либо сигналом. Этот сигнал определяет сам разработчик: то ли говорит, что фраза непонята, то ли выдает список фраз, которые пользователь может сказать в данных момент. В случае успешной проверки фраза передается синтаксическому анализатору.

Это значение присваивается строковой переменной. Синтаксический анализатор транслирует фразу пользователя в выходную, то есть как бы записывает смысл фразы во внутреннем представлении. Итак, после выполнения присваивает ей значение “<v_type> = “пиво”, которое мы должны передать в диалоговый engine для выполнения.

Если значение строки не определено, то выходная строка пуста. Это означает, что фраза не принята и необходимо предпринять определенные действия.

Вопрос о том, что делать в случае, когда парсер не понял фразу, остается за разработчиком конкретного приложения.

Можно, например, сообщить пользователю, что его фраза не понята и просьбу повторить, можно реализовать подсказку, получив из парсера все возможные фразы и подсказать пользователю, что он может сказать в данный момент, можно в структуре диалога предусмотреть вершину, которая отвечает за обработку не понятых фраз и нагружать ее в таких случаях, и при этом построить соответствующий диалог. Все это на усмотрении разработчика.

Просто важно понимать, что, если результатом работы парсера является пустая строка, то фраза не понята, и нужно предусмотреть обработку таких случаев.

Для выполнения основных функций, лексический и синтаксический анализаторы должны реализовывать следующие методы:

Кроме всего прочего необходимо создать механизмы реализации логической структуры представления грамматики.

Следует создать объект, реализующий вершины структуры, который выполняет следующие функции:

Здесь можно представить логическую структуру представления грамматики. Как уже говорилось, структура данных состоит из объектов вершин, которые сформированы в:

Списки описания фразы создается для каждого описания фразы грамматики и указатель на него помещается в соответствующее правило из списка описания правил грамматики. Список взаимодействует со списком описания правил грамматики. В связи с применением синтаксического анализа сверху вниз не возникает путаницы: вначале описано основное правило (или целевое правило), затем все остальные правила с соблюдением порядка вложенности. Каждое правило, содержащее в себе нетерминал с именем правила содержит ссылку на ячейку с этим правилом в списке определения правил. Этот способ позволяет избежать многократного повтора описаний правил, что загромождает описание грамматики.

Каждая ячейка списка содержит такую информацию: тип элемента (TERM, RULE, GRAMMAR), значение, ссылка на следующий элемент. Если элемент имеет тип RULE, то он также хранит ссылку на ячейку с описанием правила в списке описания правил грамматики. А ссылки элементов списка описаний правил грамматики хранят указатели на фразы, которые с помощью этих правил образуются.

Также следует реализовать работу со словарем: добавление слова, поиск слова, число слов в словаре, очистка словаря.

3. 2. 3 Уровень диалога

На этом уровне реализуется собственно сам диалог. Для работы диалога используется диалоговая система, реализованный фирмой CMS. Существуют также диалоговые системы, реализованные институтом CLSU. Этот тип диалоговых систем нацелен на ведение диалога высокоинтеллектуального уровня, то есть пользователь просто беседует с компьютером на любые темы. Подобные системы очень ресурсоемки и пока не дают хороших результатов по эффективности[4].

Для реализации диалога необходимо описать логическую структуру диалога (построить его дерево) и составить таблицы ответов (AG table) и скриптов (SG table).

Логическая структура является основой диалога и позволяет вести диалог в заданном направлении. Логическая структура представляет собой дерево подзадач. Каждая подзадача представлена вершиной в этом дереве, причем вершины располагаются иерархично. Вершины помечаются либо символом “n” (подзадача является необходимой для решения подзадачи верхнего уровня) либо “un” (подзадача не является необходимой для решения подзадачи верхнего уровня).

Для нашего примера о покупке пива можно выделить:

а) get_bear c типом “n”;

б) get_type c типом “n”;

в) get_mark c типом “n”;

Деревоподобная структура известна, и является очень удомной для разработчиков. На первый взгляд, классические деревья "и - или" могли использоваться для представления смысла в системах естественно-языковых диалоговых интерфейсов. Однако, полный анализ подтверждает, чтотакой тип деревьев не может отображать контекстно-зависимость языка.

Для этой цели пригодны деревья “n-un”. Каждая подзадача может быть n-подзадачей(необходимая для решения задачи верхнего уровня в логической структуре), или un-под задачей (ее решение желательно для решения задачи верхнего уровня в логической структуре).

Кроме того, узлы подзадачи получают логические значения “t” (истина), “f” (ложные) и “i” (неопределенные). Состояние задачи (“n” или “un”) и текущие значения логических узлов структуры является условием получения логического значения верхней подзадачи.

Помимо статического “n” или “un” состояния, подзадачи могут получить так называемое “NP”-состояние динамически в потоке диалога. “NP”-состояние - динамически устанавливаемое состояние неполной решаемости задачи. То есть, если пользователь простит номер телефона, то в логической структуре эта задача помечена как “NP” в связи с тем, что непонятно какая именно информация нужна. Требуемой информацией может быть как рабочий телефон, так и домашний.

Диалоговая система производит “t-i-f” вычисления и “NP”-вычисления с помощью логической структуры. “NP”-вычисления и “t-i-f” вычисления положены в основу анализа логической структуры и создают условия для интеллектуальной работы диалоговой системы.

Предположим, фраза пользователя выражает желание решить проблему <пиво>.

Имеются примеры такого вида фраз:

После синтаксического анализа, узел <пиво> логической структуры отмечен как “NP” - динамически необходимая подзадача. Тогда диалоговая система рассуждает так:

Среди подзадач <пиво> имеется одна подзадача <тип пива>, чье состояние “n” (необходимо) и которая еще не решена (“undef”). Следующая подзадача <марка>, чье состояние “un” и которая еще не решена (“undef”) и требует решения подзадач низкого уровня, так что она отмечена как “NP”. В свою очередь, задача < марка > нуждается в решениях подзадач <количество> и <сорт марки>. Эти подзадачи не решены, и, следовательно, они также являются имеют тип “undef”.

Делая подобное рассуждение, формируется NP-список:

< пиво>, < марка пива >.

Анализируя этот список, диалоговая система запускает необходимые скрипты или генерирует фразы естественного языка, адресованные пользователю с помощью AG-Table и SG-Table.

Поскольку на вершинах структуры отражается текущее состояние диалога, к вершинам привязаны записи из AG-Table и SG-Table, становится возможным генерировать ответы пользователю для продолжения диалога или выполнять определенные действия (скрипты) для получения данных или еще чего-то.

ВЫВОДЫ

Данная работа подробно освещает положительные и отрицательные стороны применения естественно-языковых диалоговых интерфейсов в маркетинге. Показана экономическая сущность подобных систем, приведены виды анализа, который требуется провести для выяснения эффективности использования интерфейсов. В настоящее время вычислительная техника завоевала ключевые позиции во многих сферах человеческой деятельности. Помимо классических применений, связанных с проведением расчетов, моделированием, сейчас успешно развивается направление “искусственный интеллект”. Цель этого направления – создание автоматизированных систем, выполняющих те же функции, что и человек, хотя бы в простейших проявлениях. В приведенной системе происходит автоматизация продажи напитков.

Обзор необходимых компонент диалоговой системы, механизмов их дальнейшей реализации создает начальный этап для проектирования естественно-языковых диалоговых интерфейсов к реляционным базам данных.

На начало